Scrum合同模式：付费止损，免费变更
编注：
1. Scrum本身就是模式，Scrum之外还有扩展模式。本文来自Scrum之父Jeff Sutherland 维护的Scrum扩展模式。
2. 本号以价值驱动，即每一篇文章都要有价值。今天的话题的触发来自【真北敏捷】群友@Stay With Me 关于合同与变更的问题。
Money for Nothing
付费止损
... the Scrum Team is acting as a vendor to develop and deliver the content of a Product Backlog ordered using High Value First. The Scrum Team realizes its value through a fixed-price agreement or perhaps a shared-risk Development Partnership whereby it receives a share of the client’s profit. There is usually a short-term profitability horizon, as is typical with fixed-scope agreements.
（背景和问题）
…Scrum团队作为一个供应商来开发和交付按价值排序的产品Backlog的内容。Scrum团队通过固定价格协议或共享风险开发伙伴关系来实现其价值。对于典型的固定范围协议，通常在盈利上缺乏长远考虑。
✥ ✥ ✥
It doesn’t make sense to spend time developing increments that cost more than they’re worth. The client is the next link down from the Scrum Team in the Value Stream, and they are interested in realizing value for themselves from an accumulated, fixed number of Product Increments delivered from the Scrum Teamas vendor.
The big picture is this: Many agreements between vendors and clients need to look far beyond the horizon of certainty into the future. That Scrum works in Sprints and has a flexible Product Backlog adds the possibility of a flexible pay-as-you-go engagement in addition to traditional fixed-price-fixed-scope agreements. Dealing with the far future can be risky business, but sometimes decision criteria become more clear and crisp closer to the point of delivery than when drafting an agreement far in advance. Both the vendor and the client want the best value from such an engagement. The vendor’s value comes primarily from the engagement income, and more subtly from the good will and reputation that it can develop both for its own sake and for what it portends for securing future engagements. The client’s value comes through the product that the vendor builds for them, whether from services that product offers to the client’s end users or from sale of the product to customers further downstream. The client’s value is reduced by the agreed price which they pay the vendor. There are several approaches to such an engagement that reduce risk or increase profitability more or less to the vendor and the client. Perhaps the dominant consideration is whether the agreement be considered fair: that is, that neither side has knowingly gained value at the expense of the other.
Because of High Value First we know that value (such as net present value) to the client of each delivered Product Increment drops monotonically over time. With perfect foresight it might be possible to identify the exact Sprint that corresponds to the point of diminishing returns: Any development beyond that point would amount to over-production and would create waste for the client. However, it is difficult to predict that point at the beginning of development. On the other hand, we can identify the decision points up front: they are the Sprints, and their Product Increments can continuously be evaluated for profitability.
While an early termination penalty in lieu of full payment could reduce both the client’s gross expenditure and net vendor income as well, forcing the vendor to take delivery of and pay for the full feature set also creates ill will. And while a pure pay-as-you go arrangement could optimize the client’s value for cost, it also reduces potential net income to the vendor. However, it also frees the vendor for other engagements whose profitability may exceed what could be gained from early-termination penalties. The vendor still suffers a small opportunity cost from being idle between the termination of the current agreement and the start of work with a new client. If it is a fixed-cost, fixed-scope agreement the vendor saves nothing by early termination and is likely to take delivery on those Sprints yielding marginal value, “just in case,” but the client may end feeling that the value recovered from the product wasn’t worth the price. The vendor is paid the full price in this case, but the client may end viewing the vendor as having taken unfair advantage of the imperfect foresight that the late product increments would be of low value.
Therefore:
Stop development when the cost of continuing exceeds the benefit that the client enterprise will receive from the development.
（解决方案与逻辑）
花了超出价值的成本来开发增量是没有意义的。在价值流中，客户是Scrum团队的下游，他们感兴趣的是，从Scrum团队作为提供者交付的累积的、固定数量的产品增量中实现价值。
重要的是：提供者和客户之间的许多协议需要能看到远远超出确定的未来。Scrum在sprint中工作，并且有一个灵活的产品待办事项列表，这增加了在传统的固定价格固定范围协议之外的灵活的现收现付服务的可能性。处理遥远的未来可能是一件冒险的事情，但有时随着交付点临近所作出的决策要比起草合同时更加清晰可靠。供应商和客户都希望从这种约定中获得最大的价值。供应商的价值主要来自于合作收入，更微妙地是来自于良好的意愿和声誉，因为它可以为自己的利益而进行开发，也可以为将来的合作提供保障。客户的价值来自于供应商为他们构建的产品，无论是产品提供给终端用户的服务，还是直接向下游客户销售产品。客户的价值随着他们付给供应商的商定的价格的提高而降低。有几种方法可以减少风险或增加利润，或多或少地增加供应商和客户的收益。也许最主要的考虑因素是协议是否公平：也就是说，双方都没有故意以牺牲对方利益为代价获得价值。
由于先做高价值的功能，我们知道每个交付产品增量的价值 (例如净现值) 随着时间的推移会单调地下降。有了完美的预见，就可以确定准确的Sprint与收益递减的对应点: 任何超出该点的开发都将导致过度生产，并为客户带来浪费。然而，在开发之初就很难预测到这一点。另一方面，我们可以预先确定决策点: 在每个sprint中，我们可以持续评估产品增量的盈利能力。虽然提前终止违约金可以减少客户的总开支和供应商的净收入，但同时这种合同也会迫使供应商倾向于拿到全部功能的费用，这也会造成不良后果。虽然一种纯粹的按需付费方式可以优化客户的成本，但也会降低供应商潜在的净利润。然而，它也让供应商释放出机会做其他业务，这些业务的盈利能力可能超过了从早期终止处罚中获得的收益。在当前协议的终止和新客户的开始工作之间，供应商仍然要承担一个小的机会成本。如果是固定成本，固定范围的协议，供应商在早期终止时还会继续把活干完，但是客户可能会觉得从产品中获得的价值是不值得付出代价的。在这种情况下，供应商得到了全部的收费，但是客户可能会认为供应商已经获得了不公平的优势，因为后期交付的产品增量是低价值的。
因此：
当持续下去的成本超出客户从中获得的收益时，停止开发。
✥ ✥ ✥
The vendor works to deliver to the client as long as ongoing work continues to increase the overall value (such as net present value) of all Product Increments.
In addition to ensuring that value to the client doesn’t decrease, also make sure that stopping development at these points won’t cripple the vendor’s profitability or value. The client may agree to pay a termination fee to the vendor in the event that they terminate the agreement early, but the client still ends paying much less than if they had pursued the agreement to the end. One can argue in all fairness that such a fee covers the vendor’s opportunity costs while lining up new business. It is best that the vendor ensure, from the beginning, that each deliverable (Sprint) has positive value to the client, so that the client doesn’t end putting the vendor at risk over the life cycle development.
For an example, see “Money for Nothing” in [1], that describes a contract set up for pay-as-you-go, where the client was given the right to terminate the contract at the end of any Sprint as long as they paid 20 percent of the cost of remaining development. The client paid $3.2 million for a product bid at $10 million and got it seventeen months early, because of incremental delivery and being able to stop development when the feature set was complete. Furthermore, they also used Change for Free to redirect some of the work into areas of higher value. In the meantime the vendor, who had set up the contract to give a profit margin of 15 percent, ended with a net profit margin of 60%. Released from the contract early, the vendor was able to pursue additional contracts instead of having to wait 17 months to do so.
This pattern focuses on the benefits that can be gained with increasing insight over time into the profitability of a previously agreed feature set or other content of a Product Increment. See also Change for Free, which capitalizes on the enterprise’s ability to better define Product Increment functionality as time goes on.
Having gained confidence from the success of short-term engagements with this safety net, both vendors and clients are more likely to take higher risk through a Development Partnership.
The Money for Nothing and Change for Free concepts originated in a class Jeff Sutherland was doing in the Netherlands in 2006.
（达到的效果）
只有持续的工作能够继续增加所有产品增量的总体价值 (如净现值) 时，供应商才会继续向客户交付产品。
除了确保客户的价值不会减少之外，还要确保在这些点停止开发不会削弱供应商的盈利能力或价值。如果客户提前终止协议，客户可能同意向供应商支付终止费，但客户仍然支付的费用远远低于他们最终达成协议时的支付费用。可以公平地说，这样的费用涵盖了供应商寻找新业务时的机会成本。最好的是，供应商从一开始就确保每个交付 (Sprint) 对客户都有积极的价值，这样客户就不会在整个生命周期的开发过程中把供应商置于危险的境地。
例如，在图1付费止损中，它描述了一种 “即付即付” 的合同，在任何Sprint结束时，客户都有权终止合同，只要他们支付剩余开发成本的20%。该客户以320万美元支付了预估的1000万开发费用，并提前17个月前获得了产品，因为这是一种增量交付，并且能够在功能集完成时停止开发。此外，他们还通过免费变更置换进来更高价值的工作。与此同时，供应商也以牺牲15%的利润的代价，另外获得了利润60%的业务。合同的早期结束，让供应商可以签订另外的合同，而不必等待17个月的时间。
这种模式关注的是，随着时间的推移，对之前达成一致的特性集或产品增量获得更多的认识，从这种认识中可以获得收益。参看免费变更，随着时间的推移，企业也可以更好地定义产品增量功能。
通过在这种安全网下的短期合作获得了成功，供应商和客户更有可能通过发展伙伴关系来承担更高的风险。
[1] Jeff Sutherland and J. J. Sutherland. “Change for Free and Money for Nothing.” In Scrum: The art of doing twice the work in half the time. New York: Crown Books, 2014, Chapter 8, ff. 193.
Picture from: PresenterMedia.com. Solution sketch courtesy of Geir Amsjø.
Change for Free
免费变更
... you have a Product Backlog ordered by High Value First under a fixed-cost, fixed-scope contract between a vendor and a client. You want to support the client with freedom to change requirements after development has started. You are supporting a single client or a client base represented by a unified perspective. Velocity has very low variance (on the order of 10% or 15%), and there is either prior experience or other verifiable expectation of being able to create an initial set of Enabling Specifications for the client request. The prospect for emergent requirements, and requirements changes, is small but non-negligible.
（背景和问题）
…在供应商和客户之间的固定成本、固定范围的合同下，您有一个高价值的产品待办事项列表。您希望在开发启动后能够自由地更改需求。您正在支持一个单一的客户或一个以统一的视角来表示的客户。开发速率具有非常低的变异 (按10%或15%)，并且有以前的经验或其他可验证的期望，可以为客户要求创建一组初始的Enabling Specifications。紧急需求和需求变更的可能性很小，但不可忽略。
✥ ✥ ✥
Some PBIs (Product Backlog Items) are somewhat context-free and independently deliverable, and you want to respond to client changes driven by clients’ desire to increase their profitability. You don’t want to allow changes that lead to significant rework, as that can lower the vendor’s ROI. On the other hand, it may take only a little investment to put a PBI on the Product Backlog and it is very little work to remove it or move it around.
Each PBI has an associated cost estimate that has been (or can be) provided by the Development Team. The Product Owner knows the ROI of each item, and the client is responsible for knowing how much value the item provides to them.
Even though you have fixed price and fixed scope, new requirements may still emerge. It serves the interests neither of the client nor of the vendor to stick to a fixed list of deliverables if there is something to gain, and nothing to lose, by renegotiating.
Anticipating that any up-front agreement of work on a complex product will not cover what clients really need, some firms have a business model based in large part on change fees for work the client is cornered into requesting after delivery. [1] Such practices erode trust, which in turn can lead to a climate of adversarial checks and balances in the long term, and all the inefficiencies that go with them.
The bottom of the requirements list is rarely mission critical for clients. However, they can still benefit if they can receive those items within the originally negotiated budget.
Therefore:
Fix the price and the scope, and make a contractual agreement to commit to the top 80% of the PBIs as ordered according to their value to the client; the vendor might exceed that 80% if the work can be done within the contracted cost. Offer clients the option of exchanging an emergent requirement for any existing PBI of equal (or lower) value to them, as long as the development cost of the new item is no more than the cost of the original.
（解决方案和逻辑）
一些PBIs (产品待办事项列表项) 在某种程度上是与上下文无关的，并且是独立的可交付的，并且您想要对客户的变更作出响应，这些变化是由客户希望提高他们的盈利能力所驱动的。您不希望变更导致重大的返工，因为这样可以降低供应商的ROI。另一方面，将PBI放在产品待办事项列表上可能只需要一点点的投资，而移除它或移动它的工作量是非常小的。
每个PBI都有一个由开发团队提供 (或可以) 提供的相关的成本估算。产品负责人知道每个项目的ROI，并且客户负责知道项目为他们提供了多少价值。
即使你有固定的价格和固定的范围，新的需求仍然会出现。如果有什么东西可以通过重新谈判来获得，而没有什么损失的话，那么它既符合客户的利益，也符合供应商的利益。
由于预期到在复杂产品上的任何前期工作都不能完全覆盖客户的需求，一些公司的业务模型是要求客户在交付后需要为变更支付费用。这样的做法侵蚀了信任，而信任反过来又会导致长期的敌对制衡的氛围，以及与之伴随的效率低下。
需求列表的底部部分很少对客户至关重要。但是，如果他们能够在最初协商的预算范围内获得这些项目的交付，他们仍然可以受益。
因此：
确定价格和范围，并按照合同约定，根据对客户的价值的由高到低，承诺完成PBI中前面80%的工作；如果可以在合同成本内完成工作，可以完成超过80%。只要新需求的开发成本不超过原来的成本，就可以允许客户用新的紧急需求置换出PBI中同等或更低价值的条目。
✥ ✥ ✥
The Product Backlog will be set up to generate Regular Product Increments that can accommodate client changes and increase overall value (as to the client) without increasing cost. With the cost capped, the vendor can establish a fixed price that yields fair profit. The focus is on Greatest Value, both for the vendor and client, in the time frame that each expects it.
This pattern works best for highly experienced Scrum Teams with a high degree of experience, both as a team and as a producer in the client domain. Each item’s cost should be estimated by the Development Team(s) before the Product Owner commits to positioning it in the Product Backlog. The success of this pattern depends on the team’s ability to estimate all PBIs accurately up-front, which in turn suggests that most PBIs should have the stature of an Enabling Specificationearly on, so it works best in low-risk domains or domains very familiar to the team. Of course, this pattern doesn’t apply to PBIs that are currently being worked on in a Sprint. Such PBIs are usually beyond the reach of negotiation.
In general, the vendor and client can work as a team to share these benefits instead of accounting them individually; see Development Partnership. Jeff Sutherland describes how it works: [1]
That’s why I came up with the idea of “Change for Free.” In a standard fixed-price contract, just say changes are free. List all the functionality you expect; for example, if you’re building a tank, you want one that can go seventy-five miles per hour and shoot ten rounds a minute, has seating for four, has AC, etc., etc.— everything you think you need for that tank. The builder looks at that description and says, Hmm, making that engine, I’ll call that 100 points, the loading mechanism, let’s call that 50, the seating, 5, etc., on down the list. At the end there is a set number of points for each feature. Then every Sprint, the customer, who in this scenario is contractually obligated to work closely with the Product Owner, can change priorities completely. Any item or feature in the Backlog can be moved anywhere else. And new features? No problem: just drop equivalently sized features from the deliverables. Oh, you want a laser-guided system now? Well, that’s 50 points of work—to compensate for that addition, let’s drop 50 points of low-priority features from the bottom of the Backlog.
This approach can become unwieldy if you are supporting multiple clients, since one client’s request will affect everyone’s schedule, and this approach to Product Backlog management sets an expectation that successive deliveries will follow each other closely in order of business value.
See also Money for Nothing.
The Money for Nothing and Change for Free 60 38599 60 23138 0 0 6457 0 0:00:05 0:00:03 0:00:02 6457concepts originated in a class Jeff Sutherland conducted in the Netherlands in 2006.
（达到的效果）
产品待办事项列表将被设置以生成常规的产品增量，以适应客户的变化并增加整体价值(对于客户来说)，而不会增加成本。随着成本的限制，供应商可以建立一个固定的价格，以获得公平的利润。对于供应商和客户来说，关注的都是最大的价值，和在他们期望的时间框架内。
这种模式对于经验丰富的了解客户领域的Scrum团队来说是最有效的。在产品负责人提交产品待办事项列表之前，每个项目的成本都应该由开发团队进行评估。这种模式的成功依赖于团队能够准确地预先估计所有PBIs的能力，这反过来又表明大多数PBIs在早期就应该具有一个Enabling Specificationearly的能力，因此它在低风险的领域或者是团队中非常熟悉的领域中工作得最好。当然，这种模式不适用于在Sprint中正在进行的PBIs。这样的PBIs通常超出了谈判的范围。
一般来说，供应商和客户可以作为一个团队来共享这些好处，而不是单独核算; 参见开发伙伴关系。Jeff Sutherland描述了它是如何工作的:
这就是为什么我提出了免费变更的想法。列出你所期望的所有功能; 例如，如果你正在建造一个坦克，你希望有一个能跑75英里每小时，每分钟发射10发，有4个座位，有空调，等等，等等，等等你认为你需要的坦克。建造者看着这个描述，说，嗯，制造那个引擎，我把它叫做100分，装载机制，让我们把它叫做50，座位，5，等等，在列表的下面。最后，每个特性都有一个点数。然后，每一个Sprint，客户，在这个场景中，都有义务与产品负责人紧密合作，可以完全改变优先级。待办事项列表中的任何项或特性都可以移动到其他任何地方。新功能? 没问题: 只需从可交付的内容中删除相同大小的特性。哦，你现在想要一个激光制导系统吗? 好吧，为了弥补这一额外的损失，我们要做50个工作，让我们从待办事项列表的底部砍掉50个低优先级的特性。
如果您支持多个客户，那么这种方法就会变得难以处理，因为一个客户的请求将影响每个人的进度，而这种对产品待办事项列表管理的方法将会产生一个预期，即连续的交付将会紧密地按照业务价值的高低顺序进行下去。
[1] Jeff Sutherland and J. J. Sutherland. “Change for Free and Money for Nothing.” In Scrum: The Art of Doing Twice the Work in Half the Time. New York: Crown Business, 2014, ff. 193.
Picture from: PresenterMedia.com. Sketch courtesy of Geir Amsjø.
欢迎加我微信入【真北敏捷】群讨论，接头暗号：真北敏捷。
阅读原文：Jeff Sutherland的相关演讲 密码: kip5